This might be a bit overkill. We're basically saying the same thing below with Starknet Devnet Options. I'm thinking we can remove the note here. What do you think?

I added it, removed it, and added it again a couple of times thinking about the design. I'm not too comfortable 100 percent with either of the versions, because I wanted to let it as clear as possible for the user that he can use these arguments from starknet-devnet, but not adding all of them here. At the same time, I feel the user can check the command doc in a quick glance and miss this "Starknet Devnet Options".

I'm ok with removing the note, but I still have the feeling the user can miss this.

Haha yeah, I see the dilemma. If we remove host and port, there's much less noise around the node section. I think it's enough, no? Here's a crude example of how I'm seeing it:

node

----
nile node
----
Run a local [starknet-devnet](https://github.com/Shard-Labs/starknet-devnet/) node.

Starknet Devnet Options
This command exposes...

Thanks. I think that should be enough indeed.

Since host and port are passed to the devnet in the the same way as the other devnet options (and the defaults match), can't we just stick with node_args as a single catch-all param?

I just wanted to let the defaults in our control, but if they match I agree it makes sense to remove them.

On second thought. I will let the host and port options as a commodity if you agree because we are using them here:

        if host == "127.0.0.1":
            network = "localhost"
        else:
            network = host
        gateway_url = f"http://{host}:{port}/"
        if DEFAULT_GATEWAYS.get(network) != gateway_url:
            write_node_json(network, gateway_url)

And if we remove them, I would need to parse the node_args to get the values anyway (is easier to catch them separately as we are currently doing).

Ahh right! Yeah, leaving them in sounds good to me. Depending on how the Nile config turns out down the road, maybe we can revisit this.

Sounds good.

👍